如果說「日誌收容」是廚師備料的過程，那「關聯分析」大概就是所有料都備齊後、一起放到鍋裡面，開始互相碰撞、產生美味菜餚的過程吧！好的鍋鏟瓢盆，就跟傳說中的廚具一樣，能讓廚師們事半功倍！
談到 SIEM 除了客戶最關心日誌怎麼收、怎麼識別之外，
另一個最關心的功能就當屬關聯分析 (Correlation) 機制了！
這個聽很多、談很多，但總是摸不著、看不著的又看似很「新潮」的詞，
其實它的角色跟功用，就是我們一般在系統或防火牆要設定告警觸發的規則，
也就是我們希望：「SIEM 應該在什麼條件下進行告警？」
所以談關聯分析的時候，其實通常也是在談「關聯分析規則」，
一個好的、完善的關聯分析機制，可以幫助組織偵測到很多不同類型的資安威脅偵測，
當日誌從端點設備、閘道端、網路流量、資料資料、身份存取匯集後，
資安工程師或分析師就可以有很高的想像力可以去設計，
來讓匯集內、外部、雲端、地端環境的日誌，能夠達到最有效的威脅偵測。
關聯分析本質上是一種「靜態式」Rule-Based 的機制，
意即我們要將想要在這個環境偵測或告警的「想像」情境，
用類似 if...else...then 的邏輯寫出來。
編寫的原則也會盡量由「大層級」往「小層級」去逐步限縮，
很像我們寫程式時，都會希望用越少的程式碼去達成一樣的功能，
因為越少的條件但能涵蓋更多的偵測範圍，
能夠讓整體關聯分析引擎運作起來非常高效，
整體的關聯分析規則也不會讓藤蔓一樣，
長到工程師難以維護的複雜層度。
我們拿一個普遍與常見的需求與範例，
帶各位邦友一起進入關聯分析的微觀世界來看看，
這邊以 IBM QRadar SIEM 的關聯規則當作範例，
看看它是怎麼寫的：
今天我們想要偵測防火牆有沒有在連續 5 分鐘內，從特定來源到特定目的，有超過 400 次的 Firewall Deny 的連線阻擋事件？
關聯規則：
Apply Excessive Firewall Denies from Single Source on events which are detected by the Local system and NOT when an event matches any of the following BB:HostDefinition: Servers and when any of these BB:CategoryDefinition: Firewall or ACL Denies with the same source IP more than 400 times, across exactly 1 destination IP within 5 minutes
讓我們重新整理這條關聯分析，
我們可以把它拆成三個順序與步驟來看，
可以知道這條規則生效的層級是由上往下遞減，
秉持適用越廣泛、越寬鬆的往上放；越具體、越細節的往下放，
來讓關聯分析可以在越少的步驟與設定的規則，
達到更好的的資安威脅偵測效果。
我們透過粗體字，可以一窺這條關聯規則的相關資訊：
當我們把想要偵測的情境，轉化爲類似 if.else 的形式後，
接下來就是去調整 (fine tuning)一些細節。
像是所謂的範圍 (Local) 是哪些？
要例外排除的伺服器 (Servers)有哪些？
任一Firewall or ACL 有哪些？
單一來源還是多個來源 IP?
單一目的還是多個目的 IP?
告警的最小次數是多少次？
要多長的頻率時間需要告警？
在上面粗體字的部分在 SIEM 系統上其實屬於一種集群或集合，
也就是我們用群集的方式來管理相似功能或目的的各個主機，
透過這樣的方式，一旦我們完成相關資訊環境的梳理後，
未來我們就能很簡單的調用這些群集在不同的關聯規則裡靈活運用。
今天是關聯分析的第一天，
我們帶了很細節的部分讓各位邦友體驗看看，
在資安工程師做完日誌收容之後，
他的下一件任務就是要開始替客戶撰寫一條條的關聯規則，
好的關聯規則帶你上天堂，不好的關聯規則帶你...繼續加班，
所以替一個新的資訊環境撰寫完整的關聯分析機制與規則，
是一件需要從大局著手、完整規劃，再逐步驗證實現的過程，
明天我們會離開樹林，開始往比較高的層級來看看，
關聯規則的廣度面向，又有哪些我們可以知道的事情？
明日是中秋連假，這邊祝各位邦友佳節愉快，
但我們鐵人賽還是會繼續與各位空中相會！
iThome鐵人賽
看影片追技術